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Abstract 

Types  have  been  used  to  describe  the  size  and  shape  of  data  structures  at  compile  time.  In  polymor¬ 
phic  languages  or  languages  with  abstract  types,  this  is  not  possible  since  the  types  of  some  objects 
are  not  known  at  compile  time.  Consequently,  most  implementations  of  polymorphic  languages  box 
data  (t.e.,  represent  an  object  as  a  pointer),  leading  to  inefficiencies.  We  introduce  a  new  compi¬ 
lation  method  for  polymorphic  languages  that  avoids  the  problems  associated  with  boxing  data. 
The  fundamental  idea  is  to  relax  the  requirement  that  code  selection  for  primitive,  polymorphic 
operations,  such  as  pairing  and  projection,  must  be  performed  at  compile  time.  Instead,  we  allow 
such  operations  to  defer  code  selection  until  link-  or  even  run-time  when  the  types  of  the  values 
are  known. 

We  formalize  our  approach  as  a  translation  into  an  explicitly- typed,  predicative  polymorphic  A- 
calculus  with  infcnsiono/ pnilymorphism.  By  ‘intensional  polymorphism”,  we  mean  that  construc¬ 
tors  and  terms  can  be  constructed  via  structural  recursion  on  types.  The  form  of  intensional 
analysis  that  we  provide  is  sufficiently  strong  to  perform  non-trivial  type-based  code  selection,  but 
it  is  sufficiently  weak  that  termination  of  operations  that  analyze  types  is  assured.  This  means 
that  a  compiler  may  always  “open  code”  intensionally  polymorphic  operations  as  soon  as  the  type 
argument  is  known  —  the  properties  of  the  target  language  ensure  that  the  specialization  will  al¬ 
ways  terminate.  We  illustrate  the  use  of  intensional  polymorphism  by  considering  a  “flattening” 
translation  for  tuples  and  a  “marshalling”  operation  for  distributed  computing.  We  briefly  consider 
other  applications  including  type  classes.  Dynamic  types,  and  “views” . 
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1  Introduction 


Types  may  be  thought  of  as  descriptions  of  data.  Compilers  for  monomorphic  languages  have 
considerable  leeway  in  choosing  data  representations,  using  types  at  compile  time  to  guide  code 
selection.  For  example,  a  Pascal  or  C  compiler  typically  uses  a  ‘flattened”  representation  of  struc¬ 
tures  (records)  in  which  consecutive  fields  are  physically  adjacent,  and  in  which  nested  structures 
are  layed  out  “in  line”.  Access  to  these  structures  is  determined  by  the  type  which  determines 
the  size  and  location  of  the  components  of  the  structure.  This  allows  the  programmer  to  gain 
considerable  control  over  the  representation  of  data  structures,  facilitating  interaction  with  ambi¬ 
ent  hardware  and  software  systems.  It  is  also  easy  to  support  a  type-safe  form  of  cast  whereby  a 
compound  data  structure  may  be  viewed  as  a  value  of  a  number  of  different  types,  provided  that 
all  such  types  describe  the  same  sequence  of  atomic  values. 

Extending  this  flexibility  to  languages  like  Modula-3  or  Standard  ML  (SML)  is  rather  more 
difficult  because  the  type  of  a  value  is  not  always  statically  apparent.  For  example,  in  Modula-3  it  is 
possible  to  manipulate  values  of  an  abstract  type  that  is  defined  in  a  separate  compilation  unit.  The 
compiler  cannot  determine  the  representation  of  the  value  because  the  implementation  type  of  the 
abstraction  is  unavailable  (at  least  until  link  time).  Similarly,  in  Standard  ML  unknown  types  arise 
not  only  because  of  separate  compilation,  but  also  because  of  the  module  system  polymorphism. 
For  example,  when  compiling  the  body  of  a  functor  whose  parameter  declares  a  type  and  operations 
on  that  type,  it  is  unknown  (and  fundamentally  unknowable!)  what  is  the  representation  of  that 
type.  Similar  problems  arise  with  ML-style  polymorphism  —  the  type  of  a  variable  may  be  only 
partially  constrained,  leaving  the  exact  shape  of  its  value  underdetermined. 

As  a  result  current  compiler  technology  for  polymorphic  languages  precludes  affording  the  pro¬ 
grammer  the  same  degree  of  control  over  data  representation  that  is  routinely  provided  in  monomor¬ 
phic  languages.  Modula-3  imposes  the  restriction  that  values  of  unknown  types  must  be  pointers 
in  order  to  ensure  that  the  representation  of  values  of  unknown  type  is  uniform  across  instances. 
Most  implementations  of  ML  impose  a  similar  restriction,  requiring  that  values  of  unknown  type  be 
“boxed”  (stored  on  the  heap  and  represented  by  a  pointer).  Early  implementations  used  a  LlSP-like 
representation  in  which  all  values  are  boxed  [5];  later  implementations  [31,  32,  30,  24,  43]  seek  to 
minimize  boxing  by  taking  advantage  of  whatever  type  information  is  manifest  in  the  program. 
Despite  these  recent  improvements,  current  implementations  still  resort  to  pointer  representations 
for  unknown  types.  Furthermore,  current  implementations  make  use  of  tag  bits  on  values  to  assist 
garbage  collection  [5]  and  to  define  polymorphic  equality  [5,  6,  18].  Thus  representations  are  further 
compromised  by  making  it  impossible  to  have  32-bit  integers  or  tag-free  tuples  with  contiguous 
layout  of  components. 

In  this  paper  we  introduce  a  new  compilation  method  for  polymorphic  languages  that  avoids 
the  difficulties  introduced  by  boxing  and  tagging  techniques.  The  fundamental  idea  is  to  relax  the 
requirement  that  code  selection  must  be  performed  at  compile  time.  In  a  monomorphic  language 
code  generation  for  primitive  operations  such  as  pairing  or  projection  is  determined  by  the  type.  For 
example,  different  code  is  generated  for  the  second  projection  at  type  float  ♦  float  than  for  int  *  int 
since  float’s  typically  take  more  space  than  int’s.  In  a  polymorphic  language  it  is  necessary  to 
compile  functions  such  as  Xx.Xy.{x,y),  in  which  the  types  of  x  and  y  are  unknown.  Which  pairing 
operation  should  be  used?  Using  boxing  the  compiler  ensures  that  x  and  y  are  represented  by 
pointers,  for  which  pairing  can  be  compiled  uniformly.  We  propose  instead  to  defer  code  selection 
to  link-  or  even  run-time  when  the  types  of  x  and  y  are  known.  This  requires  a  type-passing 
interpretation  of  polymorphism  (as  suggested  by  Harper  and  Mitchell  [21]),  together  with  suitable 
operations  for  performing  code  selection  based  on  type  parameters. 

Our  approach  is  formalized  as  a  translation  into  an  explicitly-typed,  predicative  polymorphic 
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A-calculus  with  intensional or  siructura/  [18]  polymorphism.  By  “predicative”  we  mean  that  mono¬ 
types  and  polytypes  are  separated,  with  quantifiers  ranging  only  over  monotypes.  By  “intensional 
polymorphism”  we  mean  that  type  parameters  are  not  necessarily  treated  uniformly,  as  in  the 
parametric  case  [45],  but  rather  can  significantly  affect  the  course  of  computation.  Following  Con¬ 
stable  [13,  14]  we  consider  primitive  operations  for  performing  intensional  type  analysis  [13,  14]  in 
the  form  of  structural  recursion  on  types  at  both  the  term  and  the  type  level.  Intensional  type 
analysis  is  required  at  the  type,  as  well  as  the  term,  level  in  order  to  track  the  type  of  intensionally 
polymorphic  operations.  This  feature  distinguishes  our  approach  from  other  approaches  based  on 
typecase  [49,  28]. 

The  form  of  intensional  analysis  that  we  provide  is  sufficiently  strong  to  perform  non-trivial 
type-based  code  selection,  but  it  is  sufficiently  weak  that  termination  of  operations  that  analyze 
types  is  assured.  This  means  that  the  compiler  may  always  “open  code”  intensionally  polymorphic 
operations  as  soon  as  the  type  argument  is  known  —  the  properties  of  the  target  language  ensure 
that  the  specialization  will  always  terminate.  We  illustrate  the  use  of  intensional  polymorphism 
by  considering  a  “flattening”  translation  for  tuples  and  a  “marshalling”  operation  for  distributed 
computing  (based  on  Ohori  and  Kato  [42]). 

This  paper  is  organized  as  follows.  In  Section  2  we  describe  our  approach  to  compilation  as 
a  type-based  translation  from  the  source  language,  Mini-ML,  to  the  target  language,  The 

basic  properties  of  are  stated,  and  a  few  illustrative  examples  are  given.  In  Section  3  we 
give  a  translation  from  Mini-ML  to  X^^  in  which  nested  binary  products  are  represented  as  right- 
associated  binary  products.  In  Section  4,  we  consider  the  controlled  re-introduction  of  boxing  into 
our  framework.  In  Section  5  we  cast  Ohori  and  Kato’s  distributed  ML  compilation  in  our  setting, 
using  intensional  polymorphism  to  determine  external  representations  of  types.  In  Section  6  we 
briefly  consider  other  applications  including  type  classes,  dynamic  types  and  “views”.  In  Section  7 
we  discuss  related  work,  and  in  section  8  we  summarize  and  suggest  directions  for  future  research. 

2  Type-Directed  Compilation 

In  order  to  take  full  advantage  of  type  information  during  compilation  we  consider  translations  of 
typing  derivations  from  the  implicitly-typed  ML  core  language  to  an  explicitly-typed  intermediate 
language,  following  the  interpretation  of  polymorphism  suggested  by  Harper  and  Mitchell  [21].  The 
source  language  is  based  on  Mini-ML  [12],  which  captures  many  of  the  essential  features  of  the  ML 
core  language.  The  target  language,  A-^^,  is  an  extension  of  A^^,  also  known  as  XML  [22],  a 
predicative  variant  of  Girard’s  [15,  16],  enriched  with  primitives  for  intensional  type  analysis. 
A  compiler  is  specified  by  a  relation  A;  F  >  e,  :  r  e*  that  carries  the  meaning  that  A;  F  t>  e*  :  r 
is  a  derivable  typing  in  Mini-ML  and  that  the  translation  of  the  source  term  e,  determined  by 
that  typing  derivation  is  the  Xf^^  expression  ej.  Since  the  translation  depends  upon  the  typing 
derivation  and  in  general  there  are  many  typing  derivations  of  an  expression,  it  is  possible  to 
have  many  different  translations  of  a  given  expression.  However,  all  of  the  translation  schemes  we 
consider  are  coherent  in  the  sense  that  any  two  typing  derivations  produce  observationally  equivalent 
translations  [8,  29,  21].'  Our  translations  will  have  the  property  that  1A|;  |F1  h  ct  :  |r|  is  derivable 
in  Xf^^  for  a  suitable  translation  of  contexts  and  types  into  Af^^.  This  allows  us  to  track  the  typing 
properties  of  the  translation,  and  admits  consideration  of  multi-stage  type-directed  compilation. 
The  exact  definitions  of  the  term  and  type  translations  will  vary  from  case  to  case,  but  the  general 
flavor  is  to  make  type  abstraction  and  type  instantiation  explicit,  and  to  exploit  this  type-passing 
interpretation  through  the  use  of  intensional  type  analysis  in  both  types  and  terms. 

'We  omit  explicit  consideration  of  the  coherence  of  our  translations  here. 
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2.1  Source  Language:  Mini-ML 

The  source  language  for  our  translations  is  a  variant  of  Mini-ML  [12].  The  syntax  of  Mini-ML  is 
defined  by  the  following  grammar: 


{monotypes)  r  ::= 
{polytypes)  a  ::= 


t  I  int  I  ri  r2  I  ri  X  T2 
T  I  'it.a 


{terms)  e 

{values)  V 


X  I  n  I  (ei,e2>  |  ttic  |  7r2e  | 
Ax.  e  I  ei  62  I  let  X  =  u  in  e 
X  I  n  I  (ui,  i;2)  I  Ax.  e 


Monotypes  (r)  are  either  type  variables  (t),  int,  arrow  types,  or  binary  product  types.  Polytypes  {cr) 
(also  known  as  type  schemes)  are  prenex  quantified  types.  We  write  Vti,t2i  •  •  -itn-T  to  represent 
the  polytype  Vti.Vt2-  •  •  -  .ytn.T.  The  terms  of  Mini-ML  (e)  consist  of  identifiers,  numerals  (n),  pairs, 
first  and  second  projections,  abstractions,  applications,  and  let-expressions.  Values  (u)  are  a  subset 
of  the  terms  and  include  identifiers,  integer  values,  pairs  of  values,  and  abstractions. 

We  write  [r/ijr'  to  denote  the  substitution  of  the  type  r  for  the  type  variable  t  in  the  type 
expression  r'.  We  use  A  A'  to  denote  the  union  of  two  disjoint  sets  of  type  variables,  A  and  A'. 
Similarly,  we  use  F  tt)  {x  :  tr}  to  denote  the  type  assignment  that  extends  F  so  that  x  is  assigned 
the  polytype  <t,  assuming  x  does  not  occur  in  the  domain  of  F. 

The  static  semantics  for  Mini-ML  is  given  in  Figure  1  as  a  series  of  inference  rules.  The  rules 
allow  us  to  derive  a  judgement  of  the  form  A;  F  >  e  :  r  where  A  is  a  set  of  free  type  variables  and 
F  is  a  type  assignment  mapping  identifiers  to  polytypes. 

The  two  most  interesting  rules  are  the  var  and  let  rules.  The  var  rule  allows  us  to  conclude 
that  the  variable  x  has  type  r'  under  F  and  A  if  F  assigns  to  x  the  polytype  Vti , . . . ,  and  t' 
is  obtained  from  r  by  subtstituting  “well-formed”  types  for  , . . . ,  t„.  These  types  are  well-formed 
if  their  free  type  variables  are  bound  in  some  outer  scope.  The  scope  of  type  variables  is  tracked 
explicitly  using  A,  so  the  type  is  well-formed  if  its  free  type  variables  are  contained  in  A.  The  let 
rule  allows  us  to  assign  a  polytype  (Vti, . .  .,f„.r)  to  the  variable  x  within  the  expression  e  provided 
the  following  conditions  hold:  First,  the  expression  bound  to  the  variable  x  must  type-check  with 
type  r  under  the  context  that  extends  the  type  variables  in  A  with  ti, . .  .,t„.  Second,  the  variable 
X  must  be  bound  to  a  value,  v,  instead  of  an  arbitrary  expression.  This  “value  restriction”  on 
polymorphism  [20,  33,  52]  is  needed  for  our  translation.  Wright  has  determined  empirically  that 
the  value  restriction  does  not  affect  the  vast  majority  of  ML  programs  [52]. 


2.2  Target  Language:  Af^^ 

The  target  language  of  our  translations,  Af^^,  is  based  on  A^^  [21],  a  predicative  variant  of  Girard’s 
[15,  16,  44].  The  essential  departure  from  the  impredicative  systems  of  Girard  and  Reynolds  is 
that  the  quantifier  Vf.£7  ranges  only  over  “small”  types,  or  “monotypes”,  which  do  not  include  the 
quantified  types.  This  calculus  is  sufficient  for  the  interpretation  of  ML-style  polymorphism  (see 
Harper  and  Mitchell  [21]  for  further  discussion  of  this  point.)  The  language  extends  A^^^  with 
intensional  (or  structural  [18])  polymorphism,  that  allows  ncn-parametric  functions  to  be  defined 
by  intensional  analysis  of  types. 

The  four  syntactic  classes  for  Af^^,  kinds  (A:),  constructors  {p),  types  (tr),  and  terms  (e),  are 


3 


(liar) 


(pa«r) 

(a6s) 


A;ri±l{x  :V<i,...,<„.r}c>r  :  [n, . . . ,  ,  <„]r 

A;  r  0  ei  :  ri  A;  F  t>  63  :  t-i 


(int)  A;  r  >  n  :  int 


A;  r  >  (ei.ej)  :  n  x 
AiFtt)  {r  ;  n}  >  e  :  r2 


(app) 


A;  r  >  e  ;  Ti  X  r-) 

W  ^  («  =  1,2) 

A;  F  >  TTj  e  :  r, 

A;  F  >  Cl  ;  r'  — >  r  A;  F  >  63  :  r' 


A;  F  >  Ax.  e  :  Ti  — V  A;  F  >  ci  63  ■ 

Aw{<i,...,«„};Fc>t;  :  r' 

A;  F  ti)  {x  ;  V<i, . .  >  e  :  t 


(let) 


A;Fc>  letx  =  wine  :  r 


Figure  1:  Mini-ML  Typing  Rules 


given  below: 

K  ::=  n  I  Kj  ->  K2 

H  ::=  f  I  Int  I I  x(Fi,M2)  I  I /ii[/i2]  I 
Typer«:(/x;/xi;/ix;M-f) 

a  ;:=  r(/x)  |  int  |  <ti  ->  (T2  |  c^i  x  (T2  |  'iU-.K.a 
e  :;=  x  |  ra  |  (ci,  62)*^'’''*  I  I ’’’2'’'^*  ^  |  Ax:cr.  e  |  ej  63  | 

Mv.K.e  I  e[/i]  I  typerec[F<7](^;ei;ex;e_^) 

Kinds  classify  constructors,  and  types  classify  terms.  Constructors  of  kind  name  ‘‘small  types" 
or  “monotypes”.  The  monotypes  are  generated  from  Int  and  variables  by  the  constructors  — >•  and 
X.  The  application  and  abstraction  constructors  correspond  to  the  function  kind  Ki  -4  K2.  Types 
in  include  the  monotypes,  and  are  closed  under  products,  function  spaces,  and  polymorphic 
quantification.  We  carefully  distinguish  constructors  from  types,  writing  T{p,)  for  the  type  corre¬ 
sponding  to  the  monotype  p..  The  terms  are  an  explicitly-typed  A-calculus  with  explicit  constructor 
abstraction  and  application  forms. 

The  official  syntax  of  terms  shows  that  the  primitive  operations  of  the  language  are  provided  with 
type  information  that  may  be  used  at  run  time.  For  example,  the  pairing  operation  is  (61,62)'^*  '^^. 
where  e,  :  <t,,  reflecting  the  fact  that  there  is  a  pairing  operation  at  each  pair  of  types.  In  a  typical 
implementation  the  pairing  operation  is  implemented  by  computing  the  size  of  the  components 
from  the  types,  allocating  a  suitable  chunk  of  memory,  and  copying  the  param  ters  into  that  space. 
However,  there  is  no  need  to  tag  the  resulting  value  with  type  information  because  the  projection 
operations,  e)  are  correspondingly  indexed  by  the  types  of  the  components  so  that  the 

appropriate  chunk  of  memory  can  be  extracted  from  the  tuple.  Similarly,  the  application  primitive 
ei  62)  is  indexed  by  the  domain  type  of  the  function^  and  is  used  to  determine  the  calling 
sequence  for  the  function.  We  use  a  simplified  term  syntax  without  the  types  when  the  information 
is  apparent  from  the  context.  However,  it  is  important  to  bear  in  mind  that  the  type  information 
is  present  in  the  fully  explicit  form  of  the  calculus. 

The  Typerec  and  typerec  forms  provide  the  ability  to  define  constructors  and  terms  by  structural 
induction  on  monotypes.  These  forms  may  be  thought  of  as  eliminatory  forms  for  the  kind  at 

^In  general,  application  could  eilso  depend  upon  the  range  type,  but  our  presentation  is  simplified  greatly  by 
restricting  the  dependency  to  the  domain  type. 


(kinds) 

(con’s) 

(types) 

(terms) 
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the  constructor  and  term  level.  (The  introductory  forms  are  the  constructors  of  kind  Q;  there  are 
no  introductory  forms  at  the  term  level  in  order  to  preserve  the  phase  distinction  [9,  22].)  At  the 
term  level  typerec  may  be  thought  of  as  a  generalization  of  the  typecase  operation  associated  with 
the  type  dynamic  [1]  that  provides  for  the  definition  of  a  term  by  induction  on  the  structure  of  a 
monotype.  At  the  constructor  level  Typerec  provides  a  similar  ability  to  define  a  constructor  by 
induction  on  the  structure  of  a  monotype.  As  will  become  clear  below,  it  is  crucial  to  provide  type 
recursion  at  both  the  constructor  and  term  level  so  that  the  type  of  an  intensionally  polymorphic 
operation  can  itself  be  defined  by  intensional  type  analysis. 

The  static  semantics  of  consists  of  a  collection  of  rules  for  deriving  judgements  of  the 
following  forms,  where  A  is  a  kind  assignment,  mapping  type  variables  {t)  to  kinds,  and  F  is  a  type 
assignment,  mapping  term  variables  to  types. 


A  t>  /I  ::  K 
A  0  /Xi  =  ^2  "  « 
A  >  <7 

A  >  <Ti  =  <72 
A;  r  >  e  :  <T 


is  a  constructor  of  kind  k 
fii  and  fi2  are  equivalent  constructors 
a  is  a  valid  type 
a\  and  are  equivalent  types 
e  is  a  term  of  type  a 


The  formation  and  equivalence  rules  for  constructors  are  given  in  Figures  2  and  3.  The 
formation  rules  are  largely  standard,  with  the  exception  of  the  Typerec  form.  The  constructor 
Typerec(/i;/ij;^x;M-^)  has  kind  Kifp,  is  of  kind  Q  (i-c-,  a  monotype),  /xj  is  of  kind  k,  and  and 
Px  are  each  of  kind  >/c— The  constructor  equivalence  rules  (Figure  3)  axioma- 

tize  definitional  equality  [47,  34]  of  constructors  to  consist  of  ,5-conversion  together  with  recursion 
equations  governing  the  Typerec  form.  The  level  of  constructors  -md  kinds  is  a  variation  of  Gbdel’s 
T  [17].  Every  constructor,  p,  has  a  unique  normal  form,  NF[p),  with  respect  to  the  obvious  notion 
of  reduction  derived  from  the  equivalence  rules  of  Figure  3  [47].  This  reduction  relation  is  confluent, 
from  which  it  follows  that  constructor  equivalence  is  decidable  [47]. 

The  type  formation  and  equivalence  rules  for  Xf^^  are  given  in  Figure  4.  The  rules  of  type 
equivalence  define  the  interpretation  T{p)  of  the  constructor  /x  as  a  type.  The  term  formation 
rules  are  standard  (see  Figure  5)  with  the  exception  of  the  typerec  form,  which  is  governed  by  the 
following  rule: 

A>p::Q  A  i+)  >  <7  A;  F  >  Cj  :  [lnt/t]«7 

A;  F  >  e_^  :Vfi,f2”f^-[^i/^]^  [^2/f]<^  [ — ^(^i i  ^z)/^]^ 

A;  F  t>  Cx  :  V<i,  t2"^^-[^i/^]<7'  ->■  [h/t]'^  [x(^ii  ^2)/<]<7’ 

A;  F  >  typerec[t.<7](^;  ej;  Cx :  e.,.)  :  [p/t]cr 

The  argument  constructor  p  must  be  of  kind  Q,  and  the  result  type  of  the  typerec  expression  is 
determined  as  function  of  the  argument  constructor.  Typically  the  constructor  variable  t  occurs  in 
(7  as  the  argument  of  a  Typerec  expression  so  that  \}i/t]a  is  determined  by  a  recursive  analysis  of  p. 

Type  checking  for  X^^  reduces  to  equivalence  checking  for  types  and  constructors.  In  view  of 
the  decidability  of  constructor  equivalence,  we  have  the  following  important  result: 

Proposition  2.1  (Decidability)  It  is  decidable  whether  or  not  A:  F  >  e  :  cr  is  derivable  in 

To  fix  the  interpretation  of  typerec,  we  specify  a  call-by-value,  natural  semantics  for  as  a 
relation  of  the  form  ph  e  ^  v  where  e  is  a  X^^  expression,  p  is  an  environment  mapping  variables 
to  semantic  values,  and  u  is  a  semantic  value.  Semantic  values  and  environments  are  defined  as 
follows: 

::=  n  [  (wi,  1x2)  |  {p,  Xx:a.  e)  \  {p,  e) 

::=  {xi  1-^  *->■ 


{semantic  values]  v 
[environments]  p 
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A  li)  {t  ::  «}  c*  t  ::  /£  A  >  Int  ;;  Q 


A>/ii:  n  A  > /i2  "  A  > /ii  ;;  n  A  >  ■■ 

A  > -^(/ii,P2)  ::  A  >  X(^i,/i2)  ::  n 

A  1+)  {<  ::  Ki}  > /i  :: /C2  A  >  fn  ::  k' -¥  k  A>fi2--K' 

Ao  \t  ::  Ki.fi  ::  Ki  —¥  K2  A>  fii[fi2]  « 

A  ▻  /i  : :  Q  A  ▻  /ij  : ;  k 
A  o  fi-t  ::  Q  Q  K  —¥  K  K 
A>  fix  (I  —*■  K  K  K 
A  o  Typerec(/i;/ii;/ix;/i_»)  ::  k 

Figure  2:  Formation  Rules  for  Constructors 


A  W  {<  ::  k'}  t>  fii  ::  k  A>  fi2  k' 
A  t>  (At  /c'./ii)[/<2]  =  (A‘2A]t<i  ::  « 


Ao/ij 

A  ^  fi^  "  Q  — >  Q  K  — ^  K  *“4  K 

A>  fix  fK— ^/c 

A[>Typerec(lnt;^;;/ix:/<-»)  =  fi]  ■■  « 

A>  fii  ::  Q  A>  fi2  ::  0 
A>  ft-,  ::  K 

A  >  fi-^  ::  Q  —*■  Q  K  —*■  K  —*■  K 
A>  fix  >^/c— »■« 

A  0  Typerec(->(/ii,fi2);/ii;#ix;/i->)  =  (Typerec(/<r,^i;/ix;/i-+))  (Typerecl/io.M’rt^x  '.M-^)) 

A>lypKrv:{x{fii,  fi2)]  fiy,  fix',  H-*)  =  Hx  /^i  A<2  (Typerec(/ii;/ij;/ix  ;/*-►))  (Typerec(/i2;/ii;/ix;/^-+)) 


Figure  3:  Equivalence  Rules  for  Constructors 


At>  fi  y.Q, 
^>T{fi) 


A  >  int 


A  >  <Ti  A  >  (72 

A  >(7i  X  (72 


A  >  (7i  A  t>  (72 

A  O  (7i  -»•  (72 


A  t>  T(lnt)  =  int 


A  >  /ii  n  A  >  fi2 
A  >  T(-*'(fii,fi2))  =  T[fii)  ->■  T(/i2) 


A  li)  {<  :;  k}  >  (7 
A  >  Vt-.;(c.(7 

A  >  /ii  ::  Q  A  >  fi2  ^ 

A>T(x(fii,fi2))  =T(fii)  X  T(/i2) 


Figure  4:  Type  Formation  and  Equivalence 


The  semantic  values  differ  from  syntactic  values  in  that  no  type  information  is  needed  on  data 
structures,  such  as  pairs,  and  closures  ((p,  Ax:£t.  e)  and  (p,  \t::K.  e))  are  used  instead  of  meta-level 
substitution  for  value  application.  Figure  6  defines  the  evaluation  relation  using  a  series  of  axioms 
and  inference  rules.  We  use  p  W  {x  u}  to  denote  the  extension  of  environment  p  so  that  x  is 
mapped  to  v,  assuming  that  x  is  not  in  the  domain  of  p. 

The  semantics  is  standard  except  for  the  evaluation  of  a  typerec  expression.  First,  the  normal 
form  of  the  constructor  argument  is  determined.  For  a  well-formed  program,  we  only  need  to 
determine  normal  forms  of  closed  constructors  of  kind  ft  and  these  are  never  of  the  form  Typerec(...), 
so  finding  the  normal  form  amounts  to  evaluating  the  argument  constructor.  Once  the  normal  form 
is  determined,  the  appropriate  subexpression  is  selected  and  applied  to  any  argument  constructors. 
The  resulting  function  is  in  turn  applied  to  the  “unrolling”  of  the  typerec  at  each  of  the  argument 
constructors. 

In  order  to  state  a  type  preservation  property  for  the  static  semantics  with  respect  to  our 
dynamic  semantics,  we  define  a  typing  judgement  for  semantic  values,  >  v  :  a,  and  a  judgement  for 
environments,  >  p  :  F,  as  follows: 


{int)  >  n  :  int 


(pair) 


t>  Ui  :  (7j  >  V2  :  cr^ 

>  {Vl,  V2)  :  £Ti  X  £T2 


(clos) 


>  p  :  r  0;  r  >  Ax:t7.  e  :  <7i  02 

c>  (p,  \x:a.  e)  :  <Ti  -i’  (T2 


(t-clos) 


>  p  :  r  0;  r  >  Ai::K.  e  :  Vf::K.tT 
>  (p,At::K.e)  :  W::«.cr 


t>vi:<Ti  •  •  •  >  u„  :  <r„ 

(env)  — - - — - - - 

>  {xi  >-4  vi,---,x„  *-)■  v„}  :  {xi  :  <7i,---,Xn  : 

Proposition  2.2  (Type  Preservation)  If  <d',9c>  e  :  a  and  0  t-  e  =»  u,  then  >  v  :  cr. 

By  inspection  of  the  semantic  value  typing  rules,  only  appropriate  values  occupy  appropriate  types 
and  thus  evaluation  will  not  “go  wrong”.  Furthermore,  programs  written  in  pure  Af^^  (i.e.,  without 
recursion  operators  or  recursive  types)  always  terminate. 

Proposition  2.3  (Termination)  If  e  is  an  expression  such  that  0;0  >  e  :  a,  then  there  exists  a 
semantic  value  v  such  that  0  I-  e  =»  u  and  >  v  :  a. 

A  few  simple  examples  will  help  to  clarify  the  use  of  typerec.  The  function  sizeof  of  type  Vt::ft.int 
that  computes  the  “size”  of  values  of  a  type  can  be  defined  as  follows. 

sizeof  =  Af::ft.typerec[f'.int](f;  ej;  Cx;  e_>.) 


where 

ej  =  1 

Cx  =  Afi::ft.Af2”ft-Axi:int.Ax2:int.xi -|- X2 
e-^  =  Afi::ft.Af2::ft-Axi:int.Ax2:int.l 

(Here  we  assume  that  arrow  types  are  boxed  and  thus  have  size  one.)  It  is  easy  to  check  that  sizeof 
has  the  type  Vf::ft.int.  Note  that  in  a  parametric  setting  this  type  contains  only  constant  functions. 
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(tnt)  A;  r  >  n  .  int 


(var) 


A  >  cr 

A;  r  W  {x  :  <r}  o  z  :  <T 


(pat 


A;  r  &  ei  :  (Ti  A;  F  >  63  ;  <T2 


("•) 


A;  r  >  e  ;  (7i  x  (T2 


A;rt>(ei,e2)‘'''‘'’  :ai  X  (r2  A;  F  >  e  :  a. 

A  >  ffi  A;  F  W  {i ;  (Ti }  >  e  ;  (T2 


(i=  1,2) 


(abs) 

(app) 


A;  F  o  Xx:<Ti.e  :  <Ti 
A;r  t>  ei  .  <t'  -¥  (T  A;  F  t>  62  :  (t' 


{tabs) 


A;  F  t>  Cl  62  ;  (T 
A  l±)  F  >  6  :  <r 


A;  F  &  At::K.  e  :  'ity.K.cr 


(tapp) 


A  >  p::K 
A;  F  t>  6  : 

A;F>6[;i]  :  [/i//](T 


(tree) 


A>  p  ::Q  A  W  {ir.n}  >  <r  A;  F  >  6j  ;  [\nt/t](T 
A;  F  c>  6_»  ;  V<i ,  t2'-'-^-\ti/t\<T  — f  [<2/i]o'  [ — ►(^i ,  l2)/^]<^ 

A;  Fc>  ex  :  Vti,/2"fl-[<i/<]g'  -»  [^zAjg  ->■  [x(<i,<2)/<]g 
A;  F  >  typerec[<.<T](^;ej;ex;e_^)  :  \jilt\(T 

Figure  5;  Term  Formation 


(pair) 


(war)  p  h  I  ^  p(x) 
p  H  61  =>  p  t-  62  =>  V2 


( int)  p\-  n 

pl-e  =►  (vi.vj)  ,,  , 

(P"’,^)  ;  :  .  («  =  i,2) 


p  I-  (ei ,  62)''' =>  (vi ,  i;2)  P  !■  ^rr' e  =>  i;,- 

(^)  p  h  Ax;(T.  6  ^  (p,  Ax:<7.  e)  (t-/u)  p  H  At::K.  e  =>  (p,  A<::k.  e) 
p  I-  61  ^  (p',  Xx:<r.  e)  ph  €2  =>  v'  ph  e  ^  (p',  A<:.7C.  e') 


(opp) 


p^  W  {x  I-+  U*}  I-  6  ^  V 


p  (-  61  62  ^  V 


(t-app) 


p'  K  [p/<]e'  =►  t; 


(trec-int) 


p  I-  e;  =>  V 


ph  typerec[<.(Tl(p;e;;ex;e_v)  =»  v 


pi-  e[/i]  ^  u 
(NF(p)  =  Int) 


^  h  @l/‘='/‘l<'(@l''>/‘l<'(ex[pi][A<2)) 

(typerec[t.(T  (pi;ej;ex;e^)))(typerec(<.(T](pi;ej;ex;6_^))  i;  . 

(<rec-pair) - — - — — - — -  (NF{p)  =  x(pi.  po)) 

ph  typerec[<.<r](p;ej;ex;e_>)  =>  v 

p  h  @(/i> lt\o  /‘1<^  (e_  [pi] [p2]) 

,,  (typerec[<.a-](pi;ej;ex;e_»)))(typerec[«.(7](pi;ei;ex;e_^))  »;  ,  , 

(trec-fn) - ; - - — - - ^ - - -  (iVF(p)  =  — ^•(ui ,  P2)) 

p  h  typerec[t.(r](p;ej;ex;e_>)  =>  v 


Figure  6:  Natural  Dynamic  Semantics  for  Xf^^ 
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As  another  example,  Girard’s  formulation  of  System  F  [15]  includes  a  distinguished  constant  Or 
of  type  r  for  each  type  r  (including  variable  types).  We  may  define  an  analogue  of  these  constants 
using  typerec  as  follows: 

zero  =  At::ft.typerec[t'.r(t')](^: 

where 

Cj  =  0 

Cx  =  Z2) 

e_>  =  Ati::Q.A.t2::Q.Xzi:T{ti).Xz2:T{t2).Xx:T{ti).Z2 


It  is  easy  to  check  that  zero  has  type  'it::Q.T{t),  the  “empty”  type  in  System  F  and  related  systems. 
The  presence  of  typerec  violates  parametricity  to  achieve  a  more  flexible  programming  language. 

To  simplify  the  presentation  we  usually  define  terms  such  as  zero  and  sizeof  using  recursion 
equations,  rather  than  as  a  typerec  expression.  The  definitions  of  zero  and  sizeof  are  given  in  this 
form  as  follows: 


sizeof  [I  nt] 

sizeof  [x(/ii,/r2)i 
sizeof  [->(/ii,;i2)j 


1 

sizeof[/ii]  +  sizeof[/i2] 
1 


zero[lnt] 

zero[x(/ii,/i2)] 

zero[->>(/ii,/X2)] 


0 

(zero[/ii],zero[/Z2]) 

Aa;:r(/ii).zero[/i2] 


Whenever  a  definition  is  presented  in  this  form  we  tacitly  assert  taut  it  can  be  formalized  using 

typerec. 


3  Flattening 

We  consider  the  “flat”  representation  of  Mini-ML  tuples  in  which  nested  tuples  are  represented  by 
a  sequence  of  “atomic”  values  (for  the  present  purposes,  any  non-tuple  is  regarded  as  “atomic”). 
To  simplify  the  development  we  give  a  translation  in  which  binary  tuples  are  represented  in  right- 
associated  form,  so  that,  for  example,  the  Mini-ML  type  (int  x  int)  x  int  will  be  compiled  to  the 
X¥^  type  int  x  (int  x  int).  The  compilation  makes  use  of  intension al  type  analysis  at  both  the  term 
and  constructor  levels. 

We  begin  by  giving  a  translation  from  Mini-ML  monotypes  to  Xf^^  constructors,  written  |r|,: 

if!,  =  t 
jintj,  =  Int 

In ->7-2!,  =  ->(|ri|,,|r2|<) 

In  X  r2l,  =  Prod[|ri|,][|r2|,] 

Here  Prod  is  a  constructor  of  kind  n  — >  defined  below.  The  translation  is  extended  to 

polytypes  as  follows: 

|rU  =  T{\tU) 

|Vf.(T|,  =  Vf::aH, 

Finally,  we  write  |A|  for  the  kind  assignment  mapping  t  to  the  kind  for  each  t  €  A,  and  |r|  for 
the  type  assignment  mapping  x  to  |r(x)|  for  each  x  £  dom(r). 

Proposition  3.1  The  type  translation  commutes  urith  substitution: 

|[ri,...,r„/fi,...,f„]r|t  =  [|n|t,  •  •  • ,  knit •  •  • , ^n]  kl»- 
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(var) 


FTViin . r„/<, . t„]r)C  A 


A;ri4)  {i  :  V<i, . .  >  X  :  [n , . . . ,  r„/t  i, . . . ,  <„]r  =>  r[!ri|t] 

{tnt)  A;  r  t>  n  ;  int  =>  n 
A;  r  o  ei  :  ri  =>•  e'.  A;  F  >  ej  :  r2  =>  e'j 


(pair) 

(^) 


A;  To  (ei.ea)  ;  n  x  =>  mkpair((ri|,l[|r2|t]  e[  e, 
A;  r  >  e  ;  n  x  T2  e' 


(afcs) 


A;  r  c  iTi  e  :  n  =>  projJlril,][lr2ltl  e' 
A;  r  W  {x  ;  Ti }  t>  e  ;  r2  =>  e' 


(1  =  1,2) 


(aPP) 


A;  r  >  Ax.  e  :  ri  -»•  r2  =>  Ax  :  |ri  |j .  e' 

A;  r  c>  ei  ;  r'  r  =>  e'j  A;  F  >  62  :  r'  =>  Cj 


(let) 


A;  F  Cl  62  ;  r  ^  @1’'  '*  e\  62 

A  W  {<  1 , . . . ,  <n  } ;  F  >  v  :  r'  ^  6 1 
A;  F  W  {x  ;  Vti, . . .  >  e  ;  r  ^ 


A;  F  >  let  X  =  V  in  6  :  r  => 

@|vi„  .  vti, . . . ,  t„  ::  Q.|r'|,.  e'2)  (A<i,  Q.  e[} 


Figure  7:  Flattening  Term  Translation 


The  translation  maps  Mini-ML  types  to  their  counterpart  constructors  in  Af^^,  except  that 
product  types  are  computed  using  the  constructor  Prod,  which  is  defined  as  follows: 

Prod[lnt][/i]  =  X(lnt, //) 

Prod[->(fia,fib)]lM]  =  X(->-(/ra,M6),M) 

Prod[x(/ia,/Xb)][/ii  =  x(/ia,Prod[/X6][//]) 

Informally,  the  constructor  Prod  computes  the  right-associated  form  of  a  product  of  two  types.  For 
example, 

((int  X  int)  x  intjf  =  Prod[Prod[lnt][lnt]][lnt] 

and 

(int  X  (int  x  int)(f  =  Prod[lnt][Prod[lnt][lnt]] 

and  the  equation 

A  >  Prod[Prod[lnt][lnt]][lnt]  =  Prod[lnt][Prod[lnt][lnt]]  :: 

is  derivable  in  Af^^. 

T’he  term  translation  is  given  in  Figure  3  as  a  series  of  inference  rules  that  parallel  the  typing 
rules  for  Mini-ML.  The  var  rule  turns  Mini-ML  implicit  instantiation  of  type  variables  into 
explicit  type  application.  The  let  rule  makes  the  implicit  type  abstraction  explicit.  The  translation 
of  the  primitive  operations  for  product  types  makes  use  of  three  auxiliary  functions,  mkpair,  projj 
and  proj2,  with  the  following  types: 

mkpair :  Vti,t2  "  Q-T{ti)  ->■  T(t2)  T(Prod[ti][t2]) 
proj,  :  Vti,t2  ”  n.T(Prod[ti][t2])  ->  T{ti) 
proj2  :  Vti,t2  "  f2.r(Prod[ti][f2])  ^(^2) 
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The  mkpair  operation  is  defined  as  follows,  using  the  “unofficial”  syntax  of  the  language: 

mkpair[lnt][r2]  =  Ax  :  T(lnt).  Ay  :  T'(r2).  (x,  y) 
mkpair[-».(ra,T^)][r2]  =  Ax  :  T(-^(ra,Ti)).  Ay  :  r(r2).  (x,y) 
mkpair[x(ro,T^,)][r2]  =  Ax  :  T(x(ra,-n,))- :  T’Ct’z)- (jr!  a:,  mkpair[T^,][r2](7r2  x)  y) 

The  verification  that  mkpair  has  the  required  type  proceeds  by  case  analysis  on  the  form  of  its  first 
argument,  relying  on  the  defining  equations  for  Prod.  For  example,  we  must  check  that  mkpair[lnt][r] 
has  type 

T(lnt)  -y  T{r)  -4-  T(Prod[lnt][r]) 

which  follows  from  the  definition  of  mkpair[lnt][r]  and  the  fact  that 

7’(Prod[lnt][r])  =  int  x  T{t). 

Similarly,  we  must  check  that  mkpair[x(ra,T^,)][r]  has  type 

T(x(ra,T^))  -4  T(r)  T(Prod[x(ra,T!,)][r] 

which  follows  from  its  definition,  the  derivability  of  the  equation 

T(Prod[x(r„Ti)][r])  =  r(r„)  x  T(Prod[T^][r]), 

and,  inductively,  the  fact  that  mkpair[Ti][r]  has  type  rj,  ->  r  -4  Prod[Ti][r]. 

The  operations  proji  and  proj2  are  defined  as  follows: 

proji[lnt][r2]  =  Ax  :  T(Prod(lnt][r2]).  ffi  x 
proji[-4(r<,,  Ti)][r2]  =  Ax  :  r(Prod[-4(ra,  n)][r2]).  rri  x 
proji[x(ro,  T^.)][r2]  =  Ax  :  r(Prod[x(r„,  7^)][r2]).  (tti  x,  proj,[ri,][T2](n-2  x)) 

proj2  [I  nt]  [r2]  =  Ax  :  T  ( Prod[l  nt]  [r2] ) .  7r2  x 
proj2[-4(ra,  T^,)][r2]  =  Ax  :  r(Prod[^(ra,  Ti,)][r2]).  7r2 x 
proj2[x (To,  Tj,)][r2]  =  Ax  :  r(Prod[x(r„,  Tj,)][r2]).  proj2N[r2](7r2  x) 

The  verification  that  these  constructors  have  the  required  type  is  similar  to  that  of  mkpair,  keeping 
in  mind  the  equations  governing  T(-)  and  Prod[— ][— ]. 

The  translation  given  in  Figure  3  may  be  characterized  by  the  following  type  preservation 
property. 

Theorem  3.2  1/  A;r  >  e  :  t  e',  then  (A(;  |r|  >  e' :  |rjt. 

The  right-associated  representation  does  not  capture  all  aspects  of  “flatness”.  In  particular, 
access  to  components  is  not  constant  time,  given  a  standard  implementation  of  the  pairing  and 
projection  operations.  This  may  be  overcome  by  extending  Af^^  with  n-tuples  (tuples  of  variable 
arity),  and  modifying  the  interpretation  of  the  product  type  as  follows: 

Prod[/ii][/i2]  =  Append [Tuple(ToList  /ii)][Tuple(ToList  /xi)] 

The  Tuple  constructor  has  kind  —4  Q,  where  k*  is  the  kind  of  lists  whose  elements  are  constructors 
of  kind  K.  The  Prod  constructor  coalesces  the  product  of  two  tuple  types  into  a  single  tuple  type 
whose  components  are  obtained  by  appending  the  fields  of  the  two  tuples.  Otherwise  the  ordinary 
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pair  (i.e.,  2-tuple)  of  the  types  is  formed.  The  constructors  Append  and  ToList  are  defined  using 
Typerec  and  Listrec  as  follows: 

Append  [Nil][/i]  =  /i 

Append[Cons(/xi,M2)][/i]  =  Cons(^i,  Append  [;i2][Ai]) 

ToList[lnt]  =  Cons(lnt,  Nil) 

ToList[->’(/ii,/i2)]  =  Cons(->(/ii,/i2),Nil) 

ToList[Tuple(/x)]  =  /j, 

A  rigorous  formulation  of  the  target  language  extended  with  n-tuples  is  tedious,  but  appears  to  be 
straightforward. 

4  Boxing 

When  type  arguments  to  polymorphic  functions  are  passed  explicitly,  it  is  no  longer  necessary  to  use 
boxing  to  implement  polymorphism.  For  example,  the  polymorphic  function  Xx.\y.{x,y)  compiles 
to  Ati::ft.At2::ft.Aii:ti.Ax2:f2-(a^i where  the  pairing  primitive  is  indexed  by  the  types 
of  the  components.  When  using  “flat”  representations  for  types,  the  components  of  a  pair  can  be 
large,  and  the  cost  of  creation  or  projection  can  be  considerable.  An  advantage  of  a  “boxed”  over  a 
“flat”  representation  is  that  large  aggregates  can  be  handled  atomically.  It  would  seem.  then,  that 
the  type-passing  interpretation  of  polymorphism  is  more  costly  than  the  boxing  interpretation  for 
some  applications. 

Fortunately,  boxing  is  not  incompatible  with  type-passing.  In  particular,  we  can  make  boxing 
explicit  in  the  source  and/or  target  languages  (as  suggested  by  Peyton  Jones  and  Launchbury  [30] 
and  Leroy  [32]).  This  allows  the  programmer  (or  compiler)  to  make  controlled  use  of  boxing  to 
satisfy  either  layout  requirements  (at  the  cost  of  certain  operations  being  more  expensive)  or  access 
requirements  (at  the  cost  of  introducing  indirections). 

Boxing  may  be  made  explicit  in  by  introducing  the  following  primitives: 

Box  ::Q  Q 

box  :  'it::Q.T{t)  T'(Box[f]) 
unbox  :  Vt;:n.r(Box[t])  -i-  T{t) 

In  axldition  we  enrich  the  type  language  with  types  of  the  form  boxed(cr)  and  define  T(Box[^i])  = 
boxed(r(^)).  The  Typerec  and  typerec  forms  are  extended  to  include  a  case  for  “boxed”  types  as 
follows: 

Typerec  (Box[/i];/ii;/Xx;^-,;/ib)  = 

£^[typerec[f.«7](Box[/i];ej;ex;e-^;eb)]  ' — >•  (eb[/i])  (typerec[f.(T](M;  ej;  Cx ;  e_,;  Cb))] 

with  the  obvious  associated  kind  and  type  rules. 

In  the  presence  of  explicit  boxing  we  gain  precise  control  over  data  layout.  For  example,  we 
may  introduce  two  forms  of  product  types  in  Mini-ML,  a  “flat”  form,  t\  T2,  and  a  “non-flat” 
form,  ri  x  r2,  with  the  following  translations: 

|rixr2|f  =  Prod[Box[lri|t]][Box[|r2|t]] 
ki  x*"  T2\t  =  PTOd[|ri|«][lr2|«] 
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The  constructor  Prod  is  extended  to  treat  boxed  types  atomically: 

Prod[Box[^i]][/i2]  =  x(Box[/ii],/i2) 


Through  the  use  of  boxing  we  may  control  the  trade-oflF  between  time  and  layout  constraints. 

The  interpretation  of  the  boxing  and  unboxing  primitives  is  left  unspecified.  The  simplest  inter¬ 
pretation  is  heap  allocation  —  values  of  type  boxed((7)  are  pointers  to  values  of  type  a.  As  pointed 
out  by  Leroy  [32,  Section  4],  this  simple  interpretation  is  not  always  adequate.  The  “recursive” 
wrap  and  unwrap  operations  considered  by  Leroy  may  be  defined  as  follows: 


wrap[lnt}  = 
wrap[Box[/i]]  = 
wrap[x(/ii,/i2)]  = 
wrap[->(/ii,/i2)]  = 


box[lnt] 

identity  [Box[/i]] 

box[x(Wrap[/xi],Wrap[/i2])]  o  (wrap[/x,]  x  wrap[/i2]) 
box[-»-(Wrap[/ii],Wrap[/i2])]  o  (unwrap[/ii]  -»•  wrap[/i2]) 


unwrap[lnt]  = 
unwrap[Box[/i]]  = 
unwrap[x(/ii,//2)]  = 
unwrap[->(/ii,At2)]  = 


unbox[lnt] 
identity  [Box[/i]] 

(unwrap[/<i]  x  unwrap[^2])  °  unbox[x  (Wrapj/ii],  Wrap[/Z2])] 
(wrap[/ii]  unwrap[/i2])  o  unbox[— f(Wrap[/ii],  Wrap[/i2])] 


(where  o  is  function  composition  and  product  and  function  spaces  are  extended  to  functions  in  the 
usual  way).  These  definitions  can  be  encoded  in  a  single  typerec  that  returns  a  pair  consisting  of 
the  two  functions.  The  constructor  Wrap  ::Q-¥Q  is  defined  as  follows: 

Wrap[lnt]  =  Box[lnt] 

Wrap[Box[/i]]  =  Box[/i] 

Wrap[x(/ii,M2)]  =  x(Wrap[/ii],Wrap{/i2]) 

Wrap[-)'(/ii,/i2)]  =  -♦>{Wrap[/ii],  Wrap[/i2]) 

With  this  definition  in  mind,  it  is  easy  to  check  that 

wrap  :  r(Wrap[t]) 

unwrap  :  Vt::Q.T(Wrap[t])  — >•  T(t) 


5  Marshalling 

Ohori  and  Kato  give  an  extension  of  ML  with  primitives  for  distributed  computing  in  a  hetrogenous 
environment  [42].  Their  extension  has  two  essential  features:  One  is  a  mechanism  for  generating 
globally  unique  names  (“handles”  or  “capabilities”)  that  are  used  as  proxies  for  functions  provided 
by  servers.  The  other  is  a  method  for  representing  arbitrary  values  in  a  form  suitable  for  trans¬ 
mission  through  a  network.  Integers  are  considered  transmissible,  as  are  pairs  of  transmissible 
values,  but  functions  cannot  be  transmitted  (due  to  the  hetrogenous  environment)  and  are  thus 
represented  by  proxy  using  unique  identifiers.  These  identifiers  are  associated  with  their  functions 
by  servers  that  may  be  contacted  through  a  primitive  addressing  scheme.  In  this  section  we  sketch 
how  a  variant  of  Ohori  and  Kato’s  representation  scheme  can  be  implemented  using  intensional 
polymorphism. 

To  accommodate  Ohori  and  Kato’s  primitives  the  language  is  extended  with  a  constructor 
Id  of  kind  O  ->  Q  and  a  corresponding  type  constructor  id(<T),  linked  by  the  equation  r(ld[/i])  = 
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id(T(^)).  The  Typerec  and  typerec  primitives  are  extended  in  the  obvious  way  to  account  for 
constructors  of  the  form 

Typerec  (ld[/i];/xj;/ix;/^-+;/^ic|)  =  /xij/iTyperec(M;Mi;Mx;/x->;/xid) 

£'[typerec[t.cT](ld[/i];ei;ex;e_,;ejj)]  i — >  {cij[/i])  (typerec[t.cT](/i;  e-,;  ;  e_,:  Cjj))] 

The  primitives  newid  and  rpc  are  added  with  the  following  types; 

newid  :  Vtj ::n.Vt2”fi-(r(Trans[ti])  — »•  T(Trans[t2]))  T(Trans[-^(ti,  f2)]) 
rpc  :  Vti:;n.Vf2"n-(T(Trans[— ^2)]))  7’(Trans[ti])  T(Trans[t2]) 

From  an  abstract  perspective,  newid  maps  a  function  on  representations  to  a  representation  of  the 
function  and  rpc  is  its  (left)  inverse.  The  name  newid  stems  from  the  representation  scheme,  which 
is  defined  as  follows: 

Trans[lnt]  =  Int 

Trans[-)-(/xi,/i2)]  =  ld[-i-(Trans[/ii],  Trans[/i2])] 

Trans[x(^i,/X2)]  =  X(Trans[/xi],  Trans[/i2]) 

Trans[ld(/i]j  =  \6\}i] 

A  value  of  type  T(Trans[/i])  has  no  arrow  types.  Instead,  —^(^1,1x2)  is  replaced  with  an  ld[-] 
constructor.  It  is  easy  to  check  that  Trans  is  a  constructor  of  kind  ft  — »•  fi. 

Operationally,  rpc  takes  a  proxy  identifier  of  a  remote  function,  and  a  transmissible  argument 
value.  The  argument  value  is  sent  to  the  remote  server,  the  function  associated  with  the  identifier 
is  applied  to  the  argument,  and  the  result  of  the  function  is  transmitted  back  as  the  result  of  the 
operation.  The  newid  operation  takes  a  function  between  transmissible  values,  generates  a  new. 
globally  unique  identifier  and  associates  that  identifier  with  the  function. 

The  compilation  of  Ohori  and  Kato’s  distribution  primitives  into  this  extension  of  relies 
critically  on  “marshalling”  and  “un marshalling”  operations  that  convert  values  from  a  type  to  its 
transmissible  representation  and  vice-versa.  These  are  defined  simultaneously  as  follows  using  the 
unofficial  syntax: 

M  ;  Vf  ::  ft.r(f)  -»■  T(Trans[f]) 

M[lnt]  =  Xx  :  int.x 

M[-f(/ri,^2)]  =  :  T(->’(/Ui,/i2)).newid[^i][/Z2](Ax  :  r(Trans[/ii]). 

M[M2](/  (U[/ii]  x))) 

M[x(/xi,/i2)]  =  Ax  :  r(x(/xi,/i2)).(M[^,](7ri  x),  M[/i2](7r2  a:)) 

M[ld[/xi]]  =  Xx  :T{\d[p]).x 

U  :  Vf  ::  ft.r(Trans[f])  Tit) 

U[lnt]  =  Ax  :  int.x 

U[->-(/ii,^2)]  =  A/ :  r(ld[->-(Trans[//i],Trans(/i2])])- 

Ax  ;  Tim).  U[/i2](i'pc[/Xi]|>2]  /  x)) 

U[x(/ii,/i2)]  =  Ax  :  T(x(Trans(/ti],Trans|jU2]))-(U[/xi](7ri  x),  U[/i2](7r2  x)) 

U[ld[/i]]  =  Ax  :  r(ld[^]).x 

At  arrow  types,  M  converts  the  function  to  one  that  takes  and  returns  transmissible  types  and  then 
allocates  and  associates  a  new  identifier  with  this  function  via  newid.  Correspondingly,  U  takes  an 
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identifier  of  arrow  type  and  a  marshalled  argument,  performs  an  rpc  on  the  identifier  and  argument, 
takes  the  result  and  unmarshals  it. 

The  M  and  U  functions  are  used  in  the  translation  of  client  phrases  that  import  a  server’s 
function  and  in  the  translation  of  server  phrases  that  export  functions.  The  reader  is  encouraged 
to  consult  Ohori  and  Kato’s  paper  [42]  for  further  details. 

6  Other  Applications 

In  this  section,  we  sketch  several  other  applications  of  intensional  polymorphism. 

6.1  Type  Classes 

The  language  Haskell  [25]  provides  the  ability  to  define  a  class  of  types  with  associated  operations 
called  methods.  (See  [51,  27,  49,  7]  for  various  papers  related  to  type  classes.)  The  canonical 
example  is  the  class  of  types  that  admit  equality  (also  known  as  equality  types  in  SML  [36]). 

Consider  adding  a  distinguished  type  void  (with  associated  constructor  Void)  in  such  a  way  that 
void  is  “empty”.  By  empty,  we  mean  that  no  closed  value  has  type  void.  We  can  encode  a  type  class 
definition  by  using  Typerec  to  map  types  in  the  class  to  themselves  and  types  not  in  the  class  to 
void.  In  this  fashion,  Typerec  may  be  used  to  compute  a  predicate  (or  in  general  an  n-ary  relation) 
on  types.  Definitional  equality  can  be  used  to  determine  membership  in  the  class. 

For  example,  the  class  of  types  that  admit  equality  can  be  defined  using  Typerec  as  follows: 

Eq  ::  n  D 

Eq[lnt]  =  Int 
Eq[Bool]  =  Bool 
Eq[x(/ii,/f2)]  =  x(Eq[/ii],Eq[Ai2]) 

Eq[->'(A‘i.M2)]  =  Void 
Eq[Void]  =  Void 

Here,  Eq  serves  as  a  predicate  on  types  in  the  sense  that  a  non-Void  constructor  n  is  definitionally 
equal  to  Eq[/i]  only  if  is  a  constructor  that  does  not  contain  the  constructor  —>•(—,—). 

The  equality  method  can  be  coded  using  typerec  as  follows,  where  we  assume  primitive  equality 
functions  for  int  and  bool: 

eq[lnt]  =  eqint 
eq[Bool]  =  eqbool 

eq[x(/ii,/X2)]  =  Ax:r(Eq[x(Aii,/i2)]).Ay:r(Eq[x(/ii,/i2)]). 

eq[Eq[/ii]](7rix)(7r,y)  and  eq[Eq[/X2]](7r2x)(7r2y) 
eq[— ►(/ii,/i2)]  =  Axrvoid.Aynroid.false 
eq[Void]  =  Ax:void.Aynroid.false 

It  is  straightforward  to  verify  that: 

eq  :  Vf::n.r(Eq[t])  -¥  T(Eq[t])  ->  bool 

Consequently,  eq[/i]  ei  can  be  well  typed  only  if  e\  and  have  types  that  are  definitionally  equal 
to  T(Eq[/i]).  The  encoding  is  not  entirely  satisfactory  because  eq[— ►(/ii,/i2)]  can  be  a  well-typed 
expression.  However,  the  function  resulting  from  evaluation  of  this  expression  can  only  be  applied 
to  values  of  type  void.  Since  no  such  values  exist,  the  function  can  never  be  used. 
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A  W  0  <T  A>/i;:K 

_ A;r  t>  e  :  [/i/t](T _ 

A;  r  ▻  pack  e  with  /iasHtiiK.cr  :  3t.-.K.<T 


A  >  (T  A;  r  t>  Cl  : 

A  W  {<::«};  F  ttl  >  €3  :  <t 
A;  r  c>  abstype  ej  is  < r:cr'  in  en  end 


:  <T 


Figure  8:  Typing  Rules  for  Existentials 


6.2  Dynamics 

In  the  presence  of  intensional  polymorphism  a  predicative  form  of  the  type  dynamic  [2]  may  be 
defined  to  be  the  existential  type  3t::Q.T(t).  Under  this  interpretation  the  introductory  form 
dynamic[r](e)  stands  for  pack e with r as 3t:;n.r(t).  The  eliminatory  form,typecase(rf; Cj, Cxi e_>), 
where  d  :  dynamic,  e,  :  tr,  and  ex,e->  :  is  defined  as  follows: 

abstype  d  ist::f2,  x:T{t)  in  typerec[t.cT](t;  ej;  ;  e'_^)  end 

Here  e'x  =  and  similarly  for  e'_^.  (The  typing  rules  for  pack 

and  abstype  are  given  in  Figure  8.) 

This  form  of  dynamic  type  only  allows  values  of  monomorphic  types  to  be  made  dynamic, 
consistently  with  the  separation  between  constructors  and  types  in  The  possibilities  for 

enriching  to  admit  impredicative  polymorphism  (and  hence  account  for  the  full  power  of 
dynamic  typing)  are  discussed  in  the  conclusion. 

6.3  Views 

One  advantage  of  controlling  data  representation  is  that  it  becomes  possible  to  support  a  type-safe 
form  of  casting  which  we  call  a  view.  Let  us  define  two  Mini-ML  types  ri  and  r2'to  be  similar. 
Ti  w  T2,  iff  they  have  the  same  representation  —  ie,  iff  |ri|t  is  definitionally  equivalent  to  |r2|f  in 
Af^^.  If  Ti  «  r2,  then  every  value  of  type  Ti  is  also  a  value  of  type  T2,  and  vice-versa.  For  example, 
in  the  case  of  the  right-associative  representation  of  nested  tuples,  we  have  that  rj  %  T2  iff  ti  and  T2 
are  equivalent  modulo  associativity  of  the  product  constructor,  and  a  value  of  a  (nested)  product 
type  is  a  value  of  every  other  association  of  that  type. 

Let  us  extend  the  source  language  with  a  construct  for  imposing  views.  If  e  has  type  r  and 
r  «  t',  then  the  expression  vieweasr'  has  type  r'.  By  our  definition  of  similarity,  no  coercion  or 
copying  is  implied  by  the  imposition  of  a  view.  This  follows  from  the  fact  that  similar  Mini-ML 
types  are  represented  by  definitionally  equal  Af^^  types,  and  the  fact  that  types  are  passed  to 
primitive  operations  to  determine  their  behavior.  For  example,  in  the  case  of  the  right-associative 
representation  of  tuples,  we  may  change  views  by  merely  changing  the  ascribed  type,  for  then  the 
projection  operations  are  given  the  type  of  the  view,  and  adjust  their  behavior  according  to  the 
imposed  view. 

In  contrast  to  coercion- based  interpretations  of  type  equivalence,  such  an  approach  to  views  is 
compatible  with  ref  types  in  the  sense  that  ri  ref  is  equivalent  to  T2  ref  iff  ti  is  equivalent  to  T2.  This 
means  that  we  may  freely  intermingle  updates  with  views  of  complex  data  structures,  capturing 
some  of  the  expressiveness  of  C  casts  without  sacrificing  type  safety. 
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7  Related  Work 


There  has  traditionally  been  two  interpretations  of  polymorphism,  the  explicit  style  (due  to 
Reynolds  [44]),  in  which  types  are  passed  to  polymorphic  operations,  and  the  implicit  style  (due 
to  Milner  [35]),  in  which  types  are  erased  prior  to  execution.  In  their  study  of  the  type  theory  of 
Standard  ML  Harper  and  Mitchell  [21]  argued  that  an  explicitly-typed  interpretation  of  ML  poly¬ 
morphism  has  better  semantic  properties  and  scales  more  easily  to  cover  the  full  language.  Harper 
and  Mitchell  formulated  a  predicative  type  theory,  XML,  a  theory  of  dependent  types  augmented 
with  a  universe  of  small  types,  adequate  for  capturing  many  aspects  of  Standard  ML.  This  type 
theory  was  subsequently  refined  by  Harper,  Mitchell,  and  Moggi  [22],  and  provides  the  basis  for 
this  work.  The  idea  of  intensional  type  analysis  exploited  here  was  inspired  by  the  work  of  Con¬ 
stable  [14,  13],  from  which  the  term  “intensional  analysis”  is  taken.  The  rules  for  typerec,  and  the 
need  for  Typerec,  are  derived  from  the  “universe  elimination”  rules  in  NuPRL  (described  only  in 
unpublished  work  of  Constable). 

The  idea  of  passing  types  to  polymorphic  functions  is  exploited  by  Morrison  et  al.  [40]  in  the 
implementation  of  Napier  ’88.  Types  are  used  at  run  time  to  specialize  data  representations  in 
roughly  the  manner  described  here.  The  authors  do  not,  however,  provide  a  rigorous  account  of 
the  type  theory  underlying  their  implementation  technique.  Ohori’s  work  on  compiling  record 
operations  [41]  is  similarly  based  on  a  type-passing  interpretation  of  polymorphism,  and  was  an 
inspiration  for  the  present  work.  Ohori’s  solution  is  ad  hoc  in  the  sense  that  no  general  type 
theoretic  framework  is  proposed,  but  many  of  the  key  ideas  in  his  work  are  present  here.  Jones  [26] 
has  proposed  a  general  framework  for  passing  data  derived  from  types  to  “qualified”  polymorphic 
operations,  called  evidence  passing.  His  approach  differs  from  ours  in  that  whereas  we  pass  types 
to  polymorphic  operations,  that  are  then  free  to  analyze  them,  Jones  passes  code  corresponding  to 
a  proof  that  a  type  satisfies  the  constraints  of  the  qualification.  From  a  practical  point  of  view  it 
appears  that  both  mechanisms  can  be  used  to  solve  similar  problems,  but  it  is  not  clear  what  is 
the  exact  relationship  between  the  two  approaches.  Recently  Thatte  [49]  has  suggested  a  semantics 
for  type  classes  that  is  similar  in  spirit  to  the  present  proposal,  but  lacks  the  capability  to  perform 
intensional  type  analysis  at  the  constructor  level,  a  crucial  feature  for  tracking  the  typing  properties 
of  intensionally  polymorphic  operations. 

A  number  of  authors  have  considered  problems  pertaining  to  representation  analysis  in  the 
presence  of  poylmorphism.  The  boxing  interpretation  of  polymorphism  has  been  studied  by  Peyton 
Jones  &  Launchbury  [30],  by  Leroy  [32],  by  Poulsen  [43],  and  by  Henglein  &  Jorgensen  [24],  with  the 
goal  of  minimizing  the  overhead  of  boxing  and  unboxing  at  run  time.  Of  a  broadly  similar  nature 
is  the  work  on  “soft”  type  systems  [3,  11,  23,  48,  53]  which  seek  to  improve  data  representations 
through  global  analysis  techniques.  All  of  these  methods  are  based  on  the  use  of  program  analysis 
techniques  to  reduce  the  overhead  of  box  and  tag  manipulation  incurred  by  the  standard  compilation 
method  for  jxjlymorphic  languages.  Many  (including  the  soft  type  systems,  but  not  Leroy’s  system) 
rely  on  global  analysis  for  their  effectiveness.  In  contrast  we  propose  a  new  approach  to  compiling 
polymorphism  that  affords  control  over  data  representation  without  compromising  modularity. 

Finally,  a  type-passing  interpretation  of  polymorphism  is  exploited  by  Tolmach  [50]  in  his 
implementation  of  a  tag-free  garbage  collection  algorithm.  Tolmach ’s  results  demonstrate  that 
it  is  feasible  to  build  a  run-time  system  for  ML  in  which  no  type  information  is  associated  with 
data  in  the  heap^.  Morrisett,  Harper,  and  Felleisen  [39]  give  a  semantic  framework  for  discussing 
garbage  collection,  and  provide  a  proof  of  correctness  of  Tolmach ’s  algorithm. 

^However,  types  are  passed  indpendently  ^LS  data  and  associated  with  code. 
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8  Directions  for  Future  Research 


We  have  presented  a  type-theoretic  framework  for  expressing  computations  that  analyze  types  at 
run  time.  The  key  feature  of  our  framework  is  the  use  of  structural  induction  on  types  at  both  the 
term  and  type  level.  This  allows  us  to  express  the  typing  properties  of  non  trivial  compulations 
that  perform  intensional  type  analysis.  When  viewed  as  an  intermediate  language  for  compiling 
ML  programs,  much  of  the  type  analysis  in  the  translations  can  be  eliminated  prior  to  run-time. 
In  particular,  the  prenex  quantification  restriction  of  ML  ensures  good  binding  time  separation 
between  type  arguments  and  value  arguments.  The  “value  restriction”  on  polym^irphic  functions, 
together  with  the  well-founded-ness  of  type  induction,  ensures  that  a  polymorphic  instantiation 
always  terminates.  This  provides  important  opportunities  for  optimization.  For  example,  if  a  type 
variable  t  occurring  as  the  parameter  of  a  functor  is  the  subject  of  intensional  type  analysis,  then 
the  typerec  can  be  simplified  when  the  functor  is  applied  and  t  becomes  known.  Similarly,  link-time 
specialization  is  possible  whenever  t  is  defined  in  a  separately-compiled  module.  Inductive  analysis 
of  type  variables  arising  from  let-style  polymorphism  is  ordinarily  handled  at  run-time,  but  it  is 
possible  to  expand  each  instance  and  perform  type  analysis  in  each  casu  separately. 

The  type  theory  considered  here  does  not  address  analysis  of  recursive  types.  Recursive  types 
may  be  added  to  by  enriching  the  constructor  level  with  a  constant  Rec  of  kind  (Q  12)  -+  12, 
and  adding  constants  representing  the  isomorphism  between  Rec[/i]  and  /i(Rec[/i]).  Extending 
typerec  and  Typerec  to  handle  recursive  types  is  problematic  because  of  the  negative  occurrence  of 
12  in  the  kind  of  Rec.  In  particular,  termination  can  no  longer  be  guaranteed.  For  the  application 
to  data  layout,  this  difficulty  is  not  prohibitive  because  values  of  recursive  types  are  “boxed”  (by 
the  isomorphism  mediating  the  recursion)  and  hence  not  further  analyzed.  However,  it  may  be 
important  in  other  applications  to  analyze  recursive  types.  The  most  obvious  approach  is  to  define 
evaluation  of  typerec  at  a  Rec  constructor  so  that  the  unrolling  is  done  “lazily”.  In  the  case  of 
well-founded  recursive  types  such  as  lists  and  trees,  this  approach  is  viable  because  the  values 
themselves  are  well-founded.  However,  in  general,  we  lose  termination,  which  presents  problems 
not  only  for  optimization  but  also  for  type  checking  (since  Typerec  would  no  longer  terminate). 

The  restriction  to  predicative  polymorphism  is  sufficient  for  compiling  ML  programs.  More 
recent  languages  such  as  Quest  [10]  extend  the  expressive  power  to  admit  impredicative  polymor¬ 
phism,  in  which  quantified  types  may  be  instantiated  by  quantified  types.  (Both  Girard’s  [15]  and 
Reynolds’s  [44]  calculi  exhibit  this  kind  of  poylmorphism.)  It  is  natural  to  consider  whether  the 
methods  proposed  here  iray  be  extended  to  the  impredicative  case.  Since  the  universal  quantifier 
may  be  viewed  as  a  constant  of  kind  (f2  — ^  fi)  — >•  f2,  similar  problems  arise  as  for  recursive  types. 
In  particular,  we  may  extend  type  analysis  to  the  quantified  case,  but  only  at  the  expense  of  ter¬ 
mination,  due  to  the  negative  occurrence  of  12  in  the  kind  of  the  quantifier.  Ad  hoc  solutions  are 
possible,  but  in  general  it  appears  necessary  to  sacrifice  termination  guarantees. 

Compiling  polymorphism  using  intensional  type  analysis  enables  data  representations  that  are 
impossible  using  type-free  techniques.  Setting  aside  the  additional  expressiveness  of  the  present 
approach,  it  is  interesting  to  consider  the  performance  of  a  type-passing  implementation  of  ML  as 
compared  to  the  type-free  approach  adopted  in  SML/NJ  [5].  As  pointed  out  by  Toimach  [50],  a 
type-passing  implementation  need  not  maintain  tag  bits  on  values  for  the  sake  of  garbage  collection. 
The  only  remaining  use  of  tag  bits  in  SML/NJ  is  for  polymorphic  equality,  which  can  readily 
be  implemented  using  intensional  type  analysis.  Thus  tag  bits  can  be  eliminated,  leading  to  a 
considerable  space  savings.  On  the  other  hand  it  costs  time  and  space  to  pass  type  arguments  at 
run-time,  and  it  is  not  clear  whether  type  analysis  is  cheaper  in  practice  than  carrying  tag  bits. 
An  empirical  study  of  the  relative  performance  of  the  two  approaches  is  currently  planned  by  the 
second  author,  and  will  be  reported  elsewhere. 
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The  combination  of  intensional  polymorphism  and  existential  types  [38]  raises  some  interesting 
questions.  On  the  one  hand,  the  type  dynamic  [2]  may  be  defined  in  terms  of  existentials.  On 
the  other  hand,  data  abstraction  may  be  violated  since  a  “client”  of  an  abstraction  may  perform 
intensional  analysis  on  the  abstract  type,  which  is  replaced  at  run-time  by  the  implementation  type 
of  the  abstraction.  This  suggests  that  it  may  be  advantageous  to  distinguish  two  kinds  of  types, 
those  that  are  analyzable  and  those  that  are  not.  In  this  way  parametricity  and  representation 
independence  can  be  enforced  by  restricting  the  use  of  type  analysis. 

The  idea  of  intensional  analysis  of  types  bears  some  resemblance  to  the  notion  of  reflection  [46,  4] 
—  we  may  think  of  type-passing  as  a  “reification”  of  the  meta-level  notion  of  types.  It  is  interesting 
to  speculate  that  the  type  theory  proposed  here  is  but  a  special  case  of  a  fully  reflective  type  theory. 
The  reflective  viewpoint  may  provide  a  solution  to  the  problem  of  intensional  analysis  of  recursive 
and  quantified  types  since,  presumably,  types  would  be  reified  in  a  syntactic  form  that  is  more 
amenable  to  analysis  —  using  first-order,  rather  than  higher-order,  abstract  syntax. 

It  is  important  to  investigate  further  the  relationship  between  intensional  polymorphism  and 
type  classes  [51,  27].  The  primary  difference  between  the  two  approaches  appears  to  be  a  trade¬ 
off  between  passing  types,  from  which  methods  can  be  chosen  based  on  intensional  type  analysis, 
and  passing  the  methods  themselves.  Passing  types  seems  to  give  a  better  handle  on  the  typing 
properties  of  non-parametric  operations  (through  the  use  of  Typerec  at  the  constructor  level),  but 
it  is  not  clear  what  are  the  exact  costs  and  benefits  of  each  approach. 
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